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REMARKS 

The Examiner is thanked for the performance of a thorough search. 

STATUS OF CLAIMS 

By this amendment, no claims have been cancelled and no claims have been 
amended. Claims 36 and 37 have been added. Hence, Claims 1-37 are pending in the 
application. 

REJECTIONS/OBJECTIONS BASED ON PRIOR ART 

The Office Action rejected Claims 1-5, 8-11, 14-17, 21-24, 27-30, and 33-35 
under 35 U.S.C. 103(a) as being unpatentable over Nagamoto (U.S. Patent No. 
6,334,126), and further in view of Lincke (U.S. Patent No. 6,397,259). 

The Office Action alleged that Claims 17, 21-24, 27-30, and 33-35 contain similar 
limitations as the methods discussed in Claims 1-5, 8-1 1, and 14-16. Therefore, the 
Office Action rejected Claims 17, 21-24, 27-30, and 33-35 under the rationale for 
rejection of Claims 1-5, 8-1 1, and 14-16. 

The Office Action also rejected Claims 6-7, 12-13, 18-20, 25-26, and 31-32 under 
35 U.S.C. 103(a) as being unpatentable over Nagamoto and Lincke as discussed in the 
rejection of Claims 1-5, 8-11, 14-17, 21-24, 27-30, and 33-35, and further in view of 
Bayeh (U.S. Patent No. 6,012,098). 

These rejections are respectfully traversed. 
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NAGAMOTO 

All of the claims are rejected based on Nagamoto, taken in combination with 
other references. Nagamoto discloses a data output system and method where a database 
holds data in voice, image, and text formats. After a search request from a client is 
processed, the search result is converted in accordance with the ability, function and 
capacity of the client, and is sent back to the client terminal. (Nagamoto, Abstract). 
LINCKE 

All of the claims are rejected based on Lincke, taken in combination with 
Nagamoto. The Office Action states that <c Nagamoto does not disclose said system 
generating, based on a first set of parameters, a request object", but that in the same field 
of endeavor, Lincke discloses transforming a first message into a standard data object 
which is transmitted to the source of data. Lincke discloses methods for "novel data 
compression techniques to enable wireless communications devices to complete 
transactions by exchanging a minimum number of data packets." In many circumstances, 
both the request and the response comprise a single packet. (Lincke, Abstract). 

CLAIM 1 

Among other things, Claim 1 requires: 
. . * , 

within said system generating, based on a first set of parameters, a request object; 
wherein said first set of parameters includes identity of said service; 
. . . , 

at said system converting said responses into said particular format; 
at said system generating, based on said responses, a composite response 
document in said particular format; 

at said system transforming said composite response document into a client- 
formatted response based on a second set of parameters; 

wherein said second set of parameters includes identity of said particular type of 
client; and 
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As shall be explained hereafter, Claim 1 is not obvious in light of Nagamoto, 
when taken in combination with Lincke, because neither Nagamoto nor Lincke, taken 
alone or in combination, disclose or suggest the limitations recited above. 

THE CLAIMS ARE NOT TO THE MERE CONCEPT OF CONVERTING 
DATA FORMATS BASED ON THE INTENDED RECIPIENTS CAPABILITIES 

As a preliminary matter, it should be noted that no attempt is being made to 
merely claim the idea of converting data from a format that cannot be used by the 
intended recipient of the data to a format that can be used by the intended recipient of the 
data. It is conceded that Nagamoto is a good example of a system that employs that 
general concept. 

For example, in col. 10, lines 59-64 and with reference to FIG. 5, Nagamoto states 

that 

"[w]hen the search result is image data and the communication terminal to 
which the search result should be sent (the transmission destination) does 
not have an image display function, for example, the controller 23 extracts 
text data associated with that image data and sends that text data as the 
search result." 

In other words, when the terminal cannot display an image, the image is converted to 

text. Further, in col. 10, line 65 to col. 1 1, line 3 and FIG. 5, Nagamoto states that 

"[w]hen the search result is text data whose amount exceeds the capacity 
of the communication terminal at the transmission destination, the text 
data generator 25 edits that text data in such a way that the amount of the 
text data falls within the capacity of the destination's communication 
terminal." 
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In other words, when the search result is a text too large to be displayed, the text is 

converted to a text of smaller size. Yet further, in col. 11, lines 3-8 and FIG. 5, 

Nagamoto states that 

"[w]hen the search result is text data and the communication terminal at 
the transmission destination has only a voice reproducing function, such as 
a telephone having no display device, the text-speech converter 26 
converts the text data to voice data." 

In other words, when the terminal cannot display text data, the text data is converted to 

voice. And yet further, in col. 11, lines 9-16 and FIG. 5, Nagamoto states that 

"[w]hen the search result is image data compressed by a predetermined 
system (e.g. JPEG or GIF) and only an image compression/decompression 
program of another system is installed in the communication terminal at 
the transmission destination, the compression form converter 27 
decompresses the image data and compresses again the resultant image 
data by the system of the program installed in the destination's 
communication terminal." 

In other words, when the image cannot be displayed by the terminal, the image is 

converted into an image of a format that can be recognized by the terminal. 

In sum, Nagamoto teaches that, depending on the client terminal, the search 

results can be converted into at least the following formats: (1) text, (2) text of smaller 

size, (3) voice, and (4) image of different type. 

"Converting said responses into said particular format" 

The Office Action equates the conversions described in Nagamoto with the 
limitation "at said system converting said responses into said particular format" recited in 
Claim 1. However, for the reasons given hereafter, the convert-to-client-supported- 
format operation described in Nagamoto cannot possibly qualify as "at said system 
converting said responses into said particular format". 
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Specifically, Nagamoto's convert-to-client-supported- format operation puts the 
data in a format supported by the intended recipient. In contrast, the claimed step of "at 
said system converting said responses into said particular format" does not. The fact that 
the "particular format" is not a format dictated by the capabilities of the client is clearly 
evidenced by the fact that the composite response document recited in Claim 1, which is 
in the " particular format", must be transformed in order to produce a "client-formatted 
r espo nse". Suc h a transformation would be unnecessary if the "particular format" was a 
cli ent-specific form at. 

In other words, the "particular format" recited in Claim 1 is clearly an 
intermediary format which is neither the native format of the responses received by the 
system (the responses are converted into the particular format), nor the client-specific 
format of the response documents produced by the system (the composite response 
documents must be transformed before being transmitted to the clients). Nagamoto does 
not disclose or in any way suggest converting responses into an intermediary format, and 
then converting from the intermediary format to a client-specific format. 

"Generating a composite request document in said particular format" 

Nagamoto does not describe generating a composite response document in the 

particular format based on the responses. The Office Action alleges that generating a 

"composite response document in said particular format" is described in Nagamoto, col. 

10, line 30 to col 1 1 , line 35. However, Nagamoto does not teach or in any way suggest 

generating a composite response document. In col. 10, lines 53-58 and with reference to 

FIG. 5, Nagamoto explicitly states that 

"the controller 23 works with a text data generator 25, a text speech 
converter 26 and a compression form converter 27 as needed to perform a 
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predetermined process on data acquired from the database 1 as the search 
result, so that the search result can be sent to the communication 
terminal at the transmission destination." (emphasis added). 

This paragraph, if anything, teaches that the search result is sent directly to the client 

terminal, and says nothing whatsoever about creating a composite response document 

based on the search result. Thus, the limitation of Claim 1 requiring the generation of "a 

composite response document in said particular format", is not described, or even 

suggested, by Nagamoto. 

"Generating, based on first set of parameters, a request object" 

As shall be explained hereafter, Claim 1 is not obvious in light of Nagamoto, 

when taken in combination with Lincke, because "generating, based on a first set of 

parameters, a request object; wherein said first set of parameters includes identity of said 

service" is not described in Lincke. 

Claim 1 requires generating a request object based on a first set of parameters, 

wherein the first set of parameters include the ident it y of the requested service. These 

limitations are very different from the transformation of a message into a "standard object 

data request" as described in Lincke. 

The Office Action asserts that Lincke describes generating a standard object data 

request in col. 5, lines 9-65. However, nothing in this cited paragraph suggests that any 

parameters are used to generate a "standard object data request". In fact, Lincke 

teaches "transforming" a first message into a standard object data request. In col. 5, 

lines 26-33, Lincke states that the method of transforming a first message into a standard 

object data request 

". . . comprises combining the first message received from client 
processing resources with a hypertext markup language hyperlink 
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document. The first message comprises field values and field indices 
corresponding to fields in the hypertext markup language hyperlink 
document." 

Thus, what Lincke discloses is not generating a request object based on a first set of 

parameters that include the identity of a requested service as required by Cairn 1, but 

rather the transformation of a first message into a standard HTML document, where the 

transformation is predetermined since the message apparently is pre-formatted to 

contain only fields and indices that can be represented in the HTML document. There are 

no parameters involved in the transformation, and thus the transformation always 

produces the same standard request object. 

The notion that Lincke describes transforming a message into a standard object 

data request without any parameters (much less parameters that include the identity of a 

requested service) is further strengthened by the paragraph in col. 9, lines 59-65: 

"the [method for requesting data objects from a data source] comprises 
submitting compressed representations of field values and field indices, 
transmitting a first message in packets of data from a client to a server, 
transforming the first message into a standard object data request, and 
transmitting the standard object data request to the source of data." 

Here, once again, a first message is pre-formatted to contain values and indices, and the 

message is subsequently transformed into a standard object data request. Nothing at all 

suggests that there might be parameters involved in the transformation, or that a different 

transformation is possible depending on the parameters. Furthermore, since there are no 

parameters involved in the transformation described in Lincke, there is not even a 

possibility that the identity of the service might be a part of the parameters. 

Thus, Lincke does not disclose "generating, based on a first set of parameters, a 

request object; wherein said first parameter includes identity of said service" as required 

by Claim 1. 
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With respect to the motivation to combine Lincke and Nagamoto, the Office 

Action asserts that 

"[s]ince Lincke teaches a wireless communications system providing 
packet minimized communications between a wireless client and a proxy 
server, which is similar to a process of a communication terminal when a 
search requester requests a search for information in a database and the 
search result is returned to the search requesting communication terminal 
of Nagamoto, thus, it would have been obvious to one of ordinary skill in 
the art at the time the invention was made to combine the teachings of 
Lincke and Nagamoto to include generating a request object based on a set 
of parameters." 

In other words, the Office Action asserts that the motivation to combine the teachings of 
Lincke and Nagamoto arises out of the similarity between the two systems. However, it 
is clear that Lincke and Nagamoto address two entirely different problems. Lincke, on 
one hand, addresses the problem of minimizing communications to a wireless device by 
providing methods for data compression. Nagamoto, on the other hand, addresses the 
problem of servicing requests from a variety of client terminals with different functions 
and capabilities by providing mechanisms for converting text, image, and voice data. 
Thus, one with ordinary skill in the art would not be motivated to combine, with a 
reasonable probability of success, transforming a message into a "standard object data 
request" as described in Lincke with the method and system as described in Nagamoto. 

As explained above, Nagamoto when taken in combination with Lincke, does not 
disclose or in any way suggest the Claim 1 steps of converting the responses into a 
particular format, generating a composite response document in the particular format 
based on the responses, and generating a request object based on a first set of parameters 


19 


Attorney Docket No. 50277-03 1 2 

where the parameters include identity of the requested service. Therefore, it is 
respectfully submitted that Claim 1 is allowable over the art of record. 

OTHER INDEPENDENT CLAIMS 
CLAIM 22 

Claim 22 is the "computer-readable medium" form of Claim 1. This claim has 
limitations that correspond to those discussed above, and is therefore allowable for the 
same reason as Claim 1 . 
CLAIM 17 

Claim 17 is the "system" form of Claim 1. This claim has limitations that 
correspond to those discussed above, and is therefore allowable for the same reason as 
Claim 1. 

Furthermore, Claim 17 is allowable since it includes separate elements defining 
the structure of the system which are not described in the cited references. 
Claim 17 requires: 
. . . , 

a request preprocessor, which is located separately from clients, . . .; 

said request processor operatively coupled to said request preprocessor and to one 

or more gateways, . . . ; 
one or more gateways operatively coupled between said request processor and 

said data sources, 
said post processor operatively coupled to said request processor, . . 

None of the cited references disclose, or even suggest, the use of a request preprocessor, 
request processor operatively coupled to the request preprocessor, one or more gateways 
operatively coupled between the request processor and the data sources, and post 
processor operatively coupled to the request processor. Therefore, it is respectfully 
submitted that Claim 1 7 is allowable over the art of record. 
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DEPENDENT CLAIMS 

All of the dependent claims depend directly or indirectly on one of the 
independent claims discussed above. Because each of the dependant claims includes the 
limitations of the claim upon which it depends, the dependant claims are patentable for at 
least those reasons given above. In addition, the dependent claims introduce additional 
limitations that independently render them patentable. For example: 

CLAIM 3 requires that "one of said requests invokes a search mechanism at a 
data source based on a first set of search criteria; and the step of filtering data includes 
data that originated from said data source based on a second set of search criteria". While 
Nagamoto does teach use of a "search range" and a "keyword" as a search criteria used in 
the request sent to a data source (col. 8, lines 5-9) , Nagamoto does not teach or in any 
way suggest employing a second set of criteria to filter data that originated from the data 
source. 

CLAIM 4 requires that "said first set of parameters for generating said request 
includes identity of said particular user." Nagamoto does not teach that the identity of the 
particular user makes any difference in how a search result is processed. In col. 8, lines 
1-4, Nagamoto describes the use of a Terminal ID code to represent the ability of the 
communications terminal to present the search result, and the use of a program number to 
represent the functions that the communications terminal can carry out. However, the 
Terminal ID and the program number identify the client (depicted in FIG. 1 as PC 4, 
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PDA 5, mobile phone 6, or pager 7), and NOT the identity of the particular user of the 
client (depicted in FIG. 1 as the search requester 8). 

CLAIM 21 is a "system" claim that has limitations similar to those in Claim 4, 
and is therefore allowable for the same reason as Claim 4. 

CLAIM 23 is a "computer-readable medium" claim that has limitations similar to 
those in Claim 4, and is therefore allowable for the same reason as Claim 4. 

CLAIM 8 requires 

said one or more data sources include 

a first data source that supports a first protocol and is accessible 

through a first gateway, and 
a second data source that supports a second protocol and is 

accessible through a second gateway; and 
the step of converting said responses into said particular format includes 
said first gateway converting a response from said first data source 

to said particular format; and 
said second gateway converting a response from said second data 

source to said particular format. 

As pointed out in the Office Action, in col. 18, lines 25-67, Nagamoto discloses a request 
made to a Web server instead of a database. However, nothing in Nagamoto indicates or 
even suggests that two separate and structurally different data sources can be supported at 
the same time by the Nagamoto system. While Nagamoto discloses, in separate 
embodiments, the use of a database and a Web server as the data source, nothing 
indicates that a database and a Web Server can be used in the same embodiment of the 
Nagamoto system. 

Furthermore, no two separate data sources, supported by two separate protocols 
and requiring conversion of responses according to two separate protocols, are disclosed 
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in Lincke either. The paragraphs cited by the Office Action from Lincke, namely col. 9, 
lines 30-47 (describing a Web server as a data source), col. 11, lines 8-25 (describing the 
function of a proxy connected to a single Web server), and col. 14, lines 48-64 
(describing how CGI scripts operate), do not support the notion that Linke will suggest to 
one with ordinary skill in the art that two or more separate and structurally different data 
sources, supported by two separate protocols, can be used successfully in the system 
described by Nagamoto. 

CLAIM 27 is a "computer-readable medium" claim that has limitations similar to 
those in Claim 8, and is therefore allowable for the same reason as Claim 8. 

CLAIM 15 requires the method of Claim 1 wherein: 

the method further comprises the steps of 

receiving data that indicates user-specific customizations to services; 
storing said data in a configuration database; 

searching said configuration database for said user-specific customizations 
in response to receiving said request for said service; 
said first set of parameters used to generate said request object includes said user- 
specific customizations. 

As pointed out in the discussion of Claim 4 above, nothing in Nagamoto and Lincke 

suggests that the identity of the user is used in any way by the Nagamoto and Lincke 

systems. The paragraphs from Nagamoto cited by the Office Action, namely col. 7, line 

15 to col. 8, line 17 describe the capability and functions of the client (which, as defined 

by the Nagamoto system in FIG. 1, can be a PC, PDA, mobile phone, or a pager), and not 

the user (described in Nagamoto in FIG. 1 as the search requester 8) who is actually 

using the communication terminal. In direct contrast, Claim 15 requires receiving data 

that indicates user-specific customizations to services. 
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Further, Claim 1 5 requires storing the user-specific customizations in a 
configuration database. Nothing in Nagamoto even suggests that user-specific 
customization information is stored in a configuration database. The paragraph from 
Nagamoto cited by the Office Action, col. 5, lines 55-60 describes a data source holding 
data in various formats, such as image, text, and voice. As described, the data source is 
not a configuration database, but it is rather the source of the data to which a search 
request is made. 

The Office Action further alleges that Nagamoto, in col. 6, lines 49-58, describes 
searching a configuration database for user-specific configurations. This is incorrect. 
The cited paragraph describes the operation of the Nagamoto system with reference to 
FIG. 1 : a search requester informs the server of in what format should the search result be 
transferred, and in accordance with this request the server obtains a search result from the 
data source and formats it in the proper format. In contrast, Claim 15 requires a 
configuration database holding user-specific customizations in addition to the basic 
requirements of searching a data source and returning results to a user as described in 
Claim 1. 

Finally, with respect to Claim 15, the Office Action alleges that Nagamoto, in col. 
8, lines 5-10, describes using a first set of parameters, the parameters including user- 
specific customizations, to generate the request object. This is incorrect. The cited 
paragraph describe the use of a "search range" and a "keyword" to perform the search of 
the data source itself, which is quite different from using user-specific customizations to 
generate a request object as required by Claim 15. 
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CLAIM 34 is a "computer-readable medium" claim that has limitations similar to 
those in Claim 15, and is therefore allowable for the same reason as Claim 15. 

CLAIM 16 requires 

said one or more data sources include 

a first web site accessible through a gateway, and 
a second web site accessible through said gateway; and 
the step of converting said responses into said particular format includes 

said gateway converting a first response from said first web site to said 

particular format; and 
said gateway converting a second response from said second web site to 
said particular format. 

Similarly to Claim 8, Claim 16 describes a method where there are at least two data 

sources, the two data sources being two websites accessible through a gateway. 

However, as pointed out in the discussion about Claim 8 above, nothing in Lincke 

indicates that two websites can be used in the same embodiment as data sources. The 

paragraphs cited by the Office Action from Lincke, namely col. 9, lines 30-47 with 

reference to FIG. 1, describe only one Web server 140 as a data source, and a proxy 

server 180 providing the connection to a private wireless network 172. In contrast, Claim 

16 requires two distinct websites as the data sources accessible through a gateway, where 

the gateway performs the conversion of the responses from the data sources. 

CLAIM 35 is a "computer-readable medium" claim that has limitations similar to 
those in Claim 16, and is therefore allowable for the same reason as Claim 16. 

CLAIM 6 requires the method of claim 1 wherein "the step of generating a 
composite response document in said particular format involves generating a composite 
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response document in XML." The Office Action rejected Claim 6 under 35 U.S.C. 
103(a) as being unpatentable over Nagamoto and Lincke, and further in view of Bayeh. 

Bayeh describes a technique and a method for using servlets to isolate the 
retrieval of data from the rendering of the data into a presentation format. The data 
servlet formats its output data stream for transfer to a downstream servlet. The data 
stream may be formatted using language such as XML. The rendering servlet parses this 
XML stream, and using a XSL style sheet, creates an HTML data stream as an output. 
(Bayeh, Abstract). 

The Office Action correctly points out that "Nagamoto-Lincke do not disclose the 
step of converting said responses into the particular format involves converting responses 
into XML and the step of generating a composite response document in the particular 
format involves generating a composite response document in XML." The Office Action 
further asserts that Bayeh discloses a data servlet that formats query results from a 
database to an XML. 

However, the Office Action incorrectly suggests that Bayeh describes generating 

a document in XML format. As pointed out in the discussion of Claim 1, Nagamoto and 

Lincke do not disclose generating a composite response document at all. Bayeh does not 

disclose generating a document in XML format either. In Bayeh, col. 8, lines 16-18 with 

reference to FIG. 4, it is stated that 

"[i]n the preferred embodiment of the present invention, the data Servlet 
formats its output as an Extensible Markup Language ("XML") data 
stream." (emphasis added) 

Furthermore, in the Abstract Bayeh clearly suggests that a data stream, and not a 

document, is formatted into an XML format by stating that "[t]he rendering servlet 

parses this XML data stream". Yet further, in FIG. 4, the arrow pointing from the data 
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servlet 83 to the rendering servlet 85 is clearly and unmistakenly marked as "XML data 
stream." All this clearly shows that Bayeh does not disclose a document in an XML 
format, but rather a data stream in XML format used as a temporary intermediate 
output from the data servlet to the rendering servlet. 

In contrast, Claim 6 requires that a composite response document be generated in 
an XML format. The composite response document in XML format, as required by 
Claim 6, is fundamentally different from the data stream in XML format, as described in 
Bayeh, because while the composite response document is fixed and is itself transformed 
into a client-formatted response, the data stream is a temproary intermediate which is 
used to create a separate response that is subsequently sent to the client. 

CLAIM 25 is a "computer-readable medium" claim that has limitations similar to 
those in Claim 6, and is therefore allowable for the same reason as Claim 6. 

CLAIM 12 requires the method of Claim 6 wherein 

the step of generating a request object involves generating an XML request 

document that includes unresolved links; and 
the step of transmitting requests involves resolving said undersloved links. 

The Office Action alleges that Nagamoto, in col. 19, lines 7-19 and col. 19, line 59 to col. 

20, line 15, and further in view of Lincke and Bayeh, disclose generating a request 

document including unresolved links. This is incorrect. In col. 9, lines 13-15, Nagamoto 

describes that 

"[u]pon reception of the keyword to be searched from the [user], the 
controller searches the information providing table and sends a list of 
URLs corresponding to that keyword to the communication terminal." 
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This paragraph clearly shows that Nagamoto describes returning a list of URLs to the 
client terminal, and not, as required by Claim 12, generating a request object with 
unresolved links which links are to be resolved upon transmitting the responses to the 
client. 

CLAIM 31 is a "computer-readable medium" claim that has limitations similar to 
those in Claim 12, and is therefore allowable for the same reason as Claim 12. 

CLAIM 13 depends from Claim 12, and further requires that "the step of 
generating said composite response document involves replacing said unresolved links in 
said XML request document with XML data generated based on said responses from said 
one or more data sources." As discussed above with respect with Claim 12, Nagamoto- 
Lincke-Bayeh do not describe generating a request document with unresolved links and 
resolving the links when the responses are transmitted to the client, so therefore 
Nagamoto-Lincke-Bayeh cannot possibly describe replacing the unresolved links with 
data generated based on the responses from the data sources as required by Claim 13. 

CLAIM 32 is a "computer-readable medium" claim that has limitations similar to 
those in Claim 13, and is therefore allowable for the same reason as Claim 13. 

OTHER DEPENDENT CLAIMS 

The dependent claims that are not specifically addressed above are independently 
allowable based on the patentable limitations that they introduce. However, in light of 
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the fundamental differences identified above, and to expedite the favorable resolution of 
this case, a separate argument is not given for each of these dependent claims at this time. 


CONCLUSION 

For the reasons set forth above, all pending claims are patentable over the art of 
record. Accordingly, allowance of all claims is hereby respectfully solicited. 

The Examiner is respectfully requested to contact the undersigned by telephone if 
it is believed that such contact would further the examination of the present application. 

No extension fee is believed to be due. However, to the extent necessary, 
Applicants petition for an extension of time under 37 C.F.R. § 1.136. The Commissioner 
is authorized to charge any fee that may be due in relation to this application to our 
Deposit Account No. 50-1302. 

Respectfully submitted, 

HICKMAN PALERMO TRUONG & BECKER LLP 


Dated: August 19,2003 



Brian D. Hickman, Reg. No. 35,894 


1600 Willow Street 
San Jose, California 95125-5106 
Telephone No.: (408) 414-1201 
Facsimile No.: (408) 414-1076 


CERTIFICATE OF MAILING 


I hereby certify that this correspondence is being deposited with the United States Postal Service as first class mail in 
an envelope addressed to: Commissioner for Patents, Box 1450, Alexandria, VA 22313-1450 


on August 19. 2003 by 


(Date) (Signatui 


ignature) 


29 


